When you “Navigate to” a waypoint from OpenCPN, he does the following:

1. Create a temporary route from current position to selected point. The route has only two points, start and end.
2. Activate that route.
3. If a suitable output connection is available, he sends the following NMEA messages periodically to that port.
   • ECRMB
   • ECRMC
   • ECAPB
   • ECXTE
4. The Cross-track error (XTE) output by OCPN is calculated as for Rhumb Line Sailing, i.e. straight line on Mercator chart.

If an autopilot is steering the boat, it may choose to follow GC route if it wants to. The current GPS position and the target waypoint position are available in the messages sent above.

If the A/P uses only XTE, then it is sailing Rhumb Line. Alternatively, if it ignores XTE, and computes a running GC course based on the target waypoint location and current ownship position, then it is doing GC Sailing.

If the A/P is doing GC Sailing, then you would see the XTE reported by OpenCPN diverging from zero, as expected.

Of course, other chart plotters may do this differently from OpenCPN.

Personally, I wonder why we care. Rare indeed would be the case in which a two-point route long enough to benefit from GC Sailing would be traveled without need to change course for other tactical reasons (weather, traffic, etc.). Could happen with a large motor vessel, I suppose…

Users generally prefer rhumb line because

• Course does not keep changing.
• A route on any normal paper chart is a rhumb line. If my plotter uses the same rhumb lines everything matches, such as XTE, courses and distances.

• See Getting Started > GPS Setup
• Do you have the GPS symbol in the upper right? Is it red or green? What is your signal strength? See GPS Setup & Status
• But I know my GPS is working because the GPS program shows that it is working fine. Have you closed that program before trying to connect OpenCPN to the GPS? Only one program can connect to the GPS at a time.

• The boat has to be moving to have COG and SOG values.

• Disable one of the GPS
• or Filter incoming sentences for the second GPS ignoring RMC
• or Under Options > Ships > Own Ship Check “Calculate Sog/Cog and set time interval.
• See Cruiser Forum Thread Two connections to two different GPS

If you can “see” your position in the Win10 GPS Program, OCPN would also find it if you:

1. Disconnect the GPS Device from any program using the assigned Com port.
2. Connect OCPN to the same Com port using the correct baud rate.

See OCPN wiki how to find what Com port to use

• Make sure you have downloaded the latest drivers. For BU-353-S4 use USGlobalsat Corporate
• Older Globalstar models (before BU-353-S4) don't work well with Windows after W7.
• Always plug the Puck into the same usb port. (Label your USB Hub ports with each USB device to be connected.) This is not a requirement but it makes the connections more reliable and trouble free without having to change Opencpn settings each time.
• Another approach for Windows Users:
  • When the GPS is inserted into a USB port, the comuter assigns a COM port number to that device. Go to Device Manager and look for the line Ports (COM & LPT). Click on the > to the left of this line. The newly installed device will be listed. In the case of many GPS units the driver will be listed as 'Prolific USB-to-Serial Comm Port (COMX)', where 'X' is the number that has been assigned by the computer to that USB port for that device.
  • If you now insert the GPS into another USB port you will find the computer assigns a different number to the GPS.
  • To setup your computer for maximum convenience in being able to insert the GPS into any USB port and have the same COM port number (making OpenCPN happy) you can change all USB ports to have the same COM port number for the GPS.
  • Procedure: Right-click on the line “Prolific ….”. Left-click on 'Properties'. Open the tab 'Port Settings'. Click on the button 'Advanced'. Click on the elevator button. Scroll to the COM port number you want to use for the GPS in all USB ports and click on it. (I use COM1) Click on 'OK' twice. The COM port number you selected appears in the 'Prolific … ' line. (Older versions of Windows requires refreshing)
  • But only this USB port has been changed. To make other ports the same remove the GPS and plug it into another port. If you left the Device Manager page showing you will see the 'Ports (COM&LPT) line disappear and re-appear. The 'Prolific …' line will show another COM port number. Follow the procedure above to select the same number you first used. This time when you display the list of COM ports your target COM port will show '(in use)' after it. Disregard and select it. Click on 'OK'. This brings up an error window 'Communications Port Properties' advising the selected COM port number is being used by another device etc. Click on 'Yes'. When the windows clears click on 'OK'.
  • Repeat the above for the rest of the USB ports. Now it doesn't matter which port you happen to use for the GPS the assigned COM port number is the same.
  • Now go to OpenCPN and select your common port number under Options/Connections.

• The frequency of updates from most of “normal” GPS units is 1Hz, which means once per second. Unless of course you explicitly bought one that supports higher update frequency, in which case you have to use the configuration software for that GPS unit to switch it to the mode where it produces the data more frequently.
• Options > Connections > General has “Filter Nmea course (COG) and speed (SOG) data. Filter period (Sec)

One method used for several similar purpose is to transfer the information from xxGLL to a xxTLL message. OpenCPN will understand that as an ARPA target using the same functionality as for AIS targets. You can have a general Target number, e.g. 01, and a name, e.g. “My target” and fill with the position from xxGLL on every update. Set Status to “T” and nothing in the “Reference” field. See Cruiser Forum Thread

- Getting Started - Perhaps you'd like to download some charts? We suggest using Chart Downloader.

Best to analyse the data stream with the individual xxGSV sentences etc. to understand the issue better.

Physical Changes

• Swinging Carbon fiber boom, electronic RFI.

AIS is not involved

• Use the NMEA debug window to check what's coming in to OCPN. If you device is sending individual sentences for each GNSS system, see the copied text below. You can filter out one at the time in OCPN connection properties. If your device is already combining different systems position to one GNxxx there's not much to do in OCPN more than check you've the Options→Display→Advanced→ “Chart rotation averaging time” set to at least 15 sec.
• “According to the NMEA 0183 protocol, the Talker ID serves to define the navigation system(s) used for the reported position coordinates. If only GPS, GLONASS, GALILEO etc. are used for the reported position solution the Talker ID is GP, GL, GA etc. and the errors pertain to the individual system. If satellites from multiple systems are used to obtain the reported position solution, the Talker ID is GN and the errors pertain to the combined solution. ”
• Please verify that Settings→Ships→“Calculate SOG and COG from position changes” is disabled (unchecked). This option is only to be used if you have a very old, or defective, GPS receiver that cannot calculate SOG/COG on its own, or does not transmit RMC. See CF Opencpn Post #12 & #13
• SOG 0.3kts but I am not moving! View your recorded VDR file for messages like: $GPRMC,135743,A,2352.8438,N,07615.0533,W,000.5,022.6,270322,,,A*61 where the speed is .5 knots. There may be more examples with 0.2 and 0.3 knots. The speed is reported by your GNSS receiver and thus used by OCPN. The reason why you see a constant speed is there are a new message with a reported speed before the 6 seconds watchdog is “wiping” it out. The OCPN program logic don't use a SOG reported to be exactly 0.0 but instead await the watchdog to delete COG and SOG in the same time.
  • It turns out that this is a legitimate bug. The bad code crept into the code base in 2016. One of the trusted devs apparently had a GPS receiver at the time that was acting up, so a patch was made to ignore SOG=0.0. This has been fixed with v5.6.2 See post #59

GPS AIVDO Boat Position is Jumping many miles away.

• See this entire thread. http://www.cruisersforum.com/forums/f134/opencpn-jumping-map-194531.html#post2535508 You will need to use OpenCPN NmeaData Window and a Free nmea decoders and a program like Notepad++ to figure out what the offending sentences are.
• Remember that “The NMEA standard uses two primary sentences to for AIS data !AIVDM (Received Data from other vessels) and !AIVDO (Your own vessels information)” AIS - Automatic Identification System - Information
• Problem may be from having two different Own Ship position signals at the same priority, with the additional problem that AIVDO sentences position, sog & cog are just wrong. 1. First disable all but one GPS signal. (Disconnect or turn off.) 2. Stop sending AIVDO (Use either hardware or software settings.) 3. Filter out all AIVDO messages completely. See the User Manual > Connections > Filters put “AIVDO” in the Input filtering line. Also see this thread Curious reponse in OPCN which is a discussion about filtering with two Positions available.
• There is a superb descriptions and solution in Cruiser's Forum by Tehani

Enable thw WMM World Magnetic Model please.

It makes no sense to use magnetic on true north facing mercator projections.

Ownship true north heading predictor is only displayed if true north value is available.

If HDT is not available in the nmea data stream we use HDM and variation from the WMM plugin to estimate an effective HDT.